Modeling Atomic and Open-ended Transactions

This topic presents an overview of modeling atomic and open-ended transactions in a business process.

Transactions can be modeled as atomic transactions or open-ended transactions in a business process.

An atomic transaction is an explicit transaction using the Transaction group construct. It must be modeled in a short-lived process using WS-AppServer methods. This is especially useful when the duration of the process is very short. All activities in an atomic transaction will be rolled-back which participate in the transaction.

An open-ended transaction can be modeled in a long-lived process using the Compensate and Exception events to bring a transaction flavor to the business process. Long running transactions are often used where the process requires human intervention and where interactions span major organizational boundaries.

You can implement transactional behavior in long-lived processes using crash recovery, and Exception and Compensate events. In a short-lived process or process fragments (processes that do not have human tasks or Receive Message events, you can group activities into a transaction group with rollback recovery. Any exception occurring within the transaction context automatically aborts the transaction. You can attach Exception events to a transaction context to notify the user of the failure of the transaction.

Exception handling and recovery of a consistent transaction state is explicitly modeled in a business process diagram using Exception and Compensate events.



For example, when an order is received, the order confirmation (sales order) and invoice are generated for the customer, and then a purchase order is issued to the supplier. A Context group construct groups the Generate Sales Order and Generate Invoice steps, to which Exception and Compensate events are attached. An exception occurring in either step is caught by the Exception event, which manages the fault handling logic, and the process is terminated. A similar type of fault handling occurs in the Purchase Order context, except that instead of terminating the process, the fault handling flow ends in a compensate end event. This is because the fault handling logic did not undo (compensate) the completed sales order steps. The compensate end event is caught by the compensate event in the sales order context, which then executes the modeled compensation flow. Thus, the entire order is reverted irrespective of where the unrecoverable error occurs.